🬤 rns.recipes
Markdown export · meshchat-propagation-node-timers-stop-when-the-pn-is-on-the-same-host.md
Copy the block below or save it to a .md file.
# MeshChat: propagation node timers stop when the PN is on the same host
_Help · started by NSA on Mon, Aug 31, 2026 10:57 PM_
---
## Original post
**NSA** · Mon, Aug 31, 2026 10:57 PM
SUMMARY On MeshChat v2.4.0, when the Preferred Propagation Node is set to an lxmd instance running on the same host and sharing the same RNS instance, MeshChat's background timers fire once and then stop permanently. Both last_announced_at and lxmf_preferred_propagation_node_last_synced_at freeze together. The rest of the application keeps running normally - the web UI serves, inbound announces are received and stored, and nothing is written to the log. Pointing the Preferred Propagation Node at a remote node (2 hops away over TCP) resolves it completely. Timers have run on schedule since. ENVIRONMENT - MeshChat v2.4.0, built from source at commit df5aea94 (2026-08-15) - Raspberry Pi 5, Raspberry Pi OS - Python venv, run headless as a systemd service: meshchat.py --headless --host 0.0.0.0 --port 8001 --reticulum-config-dir /home/<user>/.reticulum - rnsd v1.4.2 runs as a SEPARATE systemd service; MeshChat attaches to the shared instance - lxmd runs as a SEPARATE systemd service on the same host, also on the shared instance - Transport enabled on rnsd; two TCPClientInterfaces to public nodes - rnstatus reports: Shared Instance[rns/default] ... Serving: 3 programs (lxmd, meshchat, nomadnet) SYMPTOM With Preferred Propagation Node set to the local lxmd destination: 1. MeshChat starts normally. 2. Both timers fire once (at startup or at the first scheduled interval). 3. Neither timer ever fires again. 4. The web UI continues to return HTTP 200. 5. Inbound announces continue to be received and logged at a normal rate. 6. Nothing is logged at or around the time the next fire was due - no exception, no traceback, no warning. 7. The only recovery is restarting the service, after which the cycle repeats. EVIDENCE - BOTH TIMERS STOP TOGETHER Announce interval 3h, sync interval 3h. Service restarted, then sampled via /api/v1/config: announce: 1788189323 sync: 1788189323 delta: 0 seconds Identical to the second. Service ActiveEnterTimestamp was 12:15:22 UTC; epoch 1788189323 is 15:15:23 UTC - exactly 3h 1s after start. The timer fired once on schedule, then stopped. At the time of sampling (18:35 UTC) the next fire was 20 minutes overdue. EVIDENCE - NOT EXPLAINED BY EQUAL INTERVALS To rule out the two timers merely coinciding because both intervals were 3h, announce was changed to 1 hour while sync remained at 3 hours, and the service restarted: restart: 18:44:21 UTC BASELINE announce: 1788201862 (18:44:22) BASELINE sync: 1788201862 (18:44:22) Sampled 77 minutes later, past the 1-hour announce mark: announce: 1788201862 (77.1 min ago) FROZEN sync: 1788201862 (77.1 min ago) FROZEN Announce was 17 minutes overdue and had not fired. Both timers stopped together despite different configured intervals. EVIDENCE - APPLICATION OTHERWISE HEALTHY AT THE SAME MOMENT $ curl -s -o /dev/null -w "HTTP: %{http_code}\n" http://127.0.0.1:8001/ HTTP: 200 $ journalctl -u meshchat --since "18:50" | grep -c "Received an announce" 2490 And for the ten-minute window spanning the missed fire: $ journalctl -u meshchat --since "19:40" --until "19:50" \ | grep -v "Received an announce" (no output) CONTROL - IDENTICAL SOFTWARE, REMOTE PN, NO FAILURE A second station (Raspberry Pi 4) runs the same MeshChat version with the same systemd / venv / shared-instance arrangement. Its Preferred Propagation Node is the SAME lxmd destination as above, but reached over the network rather than through the local shared instance. It has not exhibited this failure once in roughly 12 days of continuous operation. The only material difference between the two stations is whether the propagation node is local to the host or remote. FIX - POINT AT A REMOTE PROPAGATION NODE Preferred Propagation Node changed to a remote node 2 hops away over TCP (confirmed reachable with rnpath). Sync interval 15 min, announce interval 3h. Service restarted at 20:31. Observed sync timestamps: 1788208281 20:31 1788209181 20:46 (+900) 1788210081 21:01 (+900) 1788211881 21:31 (+1800, the 21:16 fire was not sampled) And announce, which had last fired at 1788201862 (18:44:22): 1788212662 21:44:22 (+10800, exactly 3h) Both timers running on schedule. No restarts needed since the change. WHAT IS NOT ESTABLISHED The mechanism is unknown. This is a reproducible correlation between the local-propagation-node configuration and the timer stall, not a root cause. Candidates not yet distinguished: - a blocking call with no timeout in the sync path when the destination resolves through the same shared instance - an exception in a background task that is never retrieved, silently cancelling the task - something in the LXMF propagation transfer state machine that never leaves a transitional state when the peer is local It is also not established whether this requires lxmd specifically, or would also occur with MeshChat's own built-in Local Propagation Node feature enabled and selected as the preferred node. WORKAROUND Set the Preferred Propagation Node to a remote node rather than one on the same host. A local propagation node can keep running and serving other clients normally - only MeshChat's own preferred-node setting needs to point elsewhere. Happy to run further tests on this setup if anyone wants specific data.
---
## Reply 1
**NSA** · Mon, Aug 31, 2026 11:02 PM
Well, sorry for the readability of the post above. Looks like all my line breaks were stripped out.
---
## Reply 2
**Zenith** · Mon, Aug 31, 2026 11:02 PM
MeshChat is EOL with many breaking bugs, and I'm a bit annoyed the author refuses to archive it. Upgrade to MeshChatX https://meshchatx.com/
---
## Reply 3
**Anonymous** · Mon, Aug 31, 2026 11:03 PM
https://dontpastetheai.com/angry/
---
## Reply 4
**NSA** · Mon, Aug 31, 2026 11:04 PM
Thanks for the reply. That's unfortunate.
---
## Reply 5
**Zenith** · Mon, Aug 31, 2026 11:05 PM
**Anonymous** wrote:
> https://dontpastetheai.com/angry/
LOL. Holy shit, I'm using this one
---
## Reply 6
**NSA** · Mon, Aug 31, 2026 11:12 PM
I'm not familiar with MeshChatX. I'll check out the link, thank you! Sounds like it's better supported and in more active development that MeshChat?
---
## Reply 7
**Mark** · Tue, Sep 1, 2026 10:05 PM
I removed the original MeshChat from the software list in the manual a while back because of these issues, but at this point I should probably add a clear note that the old MeshChat is no longer updated, uses a very outdated RNS build integrated into it, and shouldn't be used. A lot of people get confused when they use it and find all kinds of stuff not working.
---
## Reply 8
**Boltic** · Tue, Sep 1, 2026 11:16 PM
Thank you, I was fooled by the AI that said several months ago that its routing is not only based on this and that there are other types of routing as well (:
I hope you are feeling better and are always well.
I hope the Reticulum project progresses and becomes better than before, it is true that it is not yet completely replaceable for the Internet, but I had a crush on i2p at one time for this purpose, which is practically useless, and I was excited when I saw your project a few years ago.
---